Flexible Bus Media Redundancy

This paper proposes a flexible approach to bus media redundancy in Controller Area Network (CAN) fieldbuses, both to improve the bandwidth by transmitting different traffic in different channels or to promote redundancy by transmitting the same message in more than one channel. Specifically the proposed solution is discussed in the context of Flexible Time-Triggered protocol over CAN (FTTCAN) and inherits the online scheduling flexibility of FTTCAN, enabling on-the-fly modifications of the traffic conveyed in the replicated buses. Flexible bus media redundancy is useful to fulfill application requirements in terms of additional bandwidth or to react to bus failures leading the system to a degraded operational mode, without compromising safety. The arguments for and against flexible bus media redundancy in the context of FTT-CAN are also discussed in detail. 1 FTT-CAN With Multiple Buses Basis FTT-CAN (Flexible Time-Triggered communication protocol on CAN) [1] has been developed with the main purpose of combining a high level of operational flexibility with timeliness guarantees. It uses the dual-phase elementary cycle concept to isolated time and event-triggered communication. The time-triggered traffic is scheduled online in a particular node called a master, facilitating online admission control of requests, thus being managed in a flexible way, under guaranteed timeliness. The protocol relies on a relaxed master-slave medium access control in which the same master message triggers the transmission of messages in several slaves simultaneously (master/multi-slave). Eventual collisions between slave messages are handled by the native distributed arbitration of CAN. FTT-CAN slots the bus time in consecutive Elementary Cycles (ECs) with fixed duration. All nodes are synchronized at the start of each EC by the reception of a particular message known as an EC Trigger Message (TM), which is sent by the master node. Within each EC the protocol defines two consecutive windows, asynchronous (law in Figure 1 stands for length of asynchronous window) in and synchronous (lsw in Figure 1 stands for length of synchronous window), that correspond to two separate phases (see Figure 1). The first is used to convey event-triggered traffic (AM in Figure 1 stands for Asynchronous Messages) and the second is used to convey time-triggered traffic (SM in Figure 1 stands for Synchronous Messages). Between these two windows there is a guardian time to guarantee the temporal isolation (α in Figure 1). The synchronous window of the n EC has a duration that is set according to the traffic scheduled for it. The schedule for each EC is conveyed by the respective EC trigger message (see Figure 2). Since this window is placed at the end of the EC, its starting instant is variable and it is also encoded in the respective EC trigger message. Figure 1. The Elementary Cycle The communication requirements are held in a database located in the master node [1], the System Requirements Database (SRDB). This database holds several components, one of which is the Synchronous Requirements Table (SRT), that contains the description of the periodic message streams. Based on the SRT, an online scheduler builds the synchronous schedules for each EC. These schedules are then inserted in the data area of the appropriate trigger message (see Figure 2) and broad casted with it. Due to the online nature of the scheduling function, changes performed in the SRT at run time will be reflected in the bus traffic within a bounded delay, Figure 2. master/multi-slave access control and EC schedule coding scheme resulting in a flexible behavior. One recent improvement on the FTT-CAN is the use of the master to control more than one buses in the system [18][19]. Using more than one CAN bus improves both the fault tolerance of the system and the available bandwidth, since messages can be transmitted on different buses. This solution provides additional bandwidth and overcomes the single point of failure of a non replicated CAN bus [18]. In this way, multiple buses can be used either to improve the bandwidth by transmitting different traffic in different channels or to promote redundancy by transmitting the same message in more than one channel. This architecture (see Figure 3) inherits the dispatching flexibility of FTT-CAN, enabling online changes on the traffic conveyed in the channels. This is useful to fulfill application requirements in terms of additional bandwidth or to react to bus failures leading the system to a degraded operational state, without compromising safety. Figure 3. FTT-CAN using multiple buses Notice that slaves can be connected to just one CAN bus or to a set of buses, depending on the tasks that a specific slave has to perform, on the dependability level and on the bandwidth requirements. Similarly to the single bus system case, all the buses must convey a synchronized Trigger Message, with the same Elementary Cycle in all of them. That is, the Trigger Messages are issued to all the buses at the same time, dividing the bus time in all buses in the same way. Figure 4 presents an example with two buses. In the small example of Figure 4 synchronous message 1 is replicated in both buses improving its dependability. Figure 4. Bus timing with two buses In contrast, synchronous messages 2 and 3 do not require redundancy and, thus, are not transmitted in both buses. In fact, as it can be seen in Figure 3, the proposed system also includes replicated masters, adopting a leaderfollower behavior. The system only has a single active master at each time, being all the others backup masters. In case of an error in the active master, one backup master will become active since the previous active will be stopped (fail silent) . The master nodes are located at the end of the buses and the number of backup masters at one end of the buses equals the number of backup masters at the opposite end. This facilitates the bus error detection since, one Trigger Message omission can be easily detected by the master located in the opposite end of the bus. In this way, if a Trigger Message is omitted the backup master located at the opposite end of the bus will inform the active master of the error. The active master, if not crashed, could then re-schedule the traffic to the nonfaulty buses. 2 Pros and Cons of Flexible Bus Media Redundancy This section presents the arguments for and against flexible bus media redundancy in the context of FTTCAN. A multiple bus FTT-CAN architecture inherits most of the good properties of FTT-CAN, and adds some others, namely: • Increased bandwidth • Increased resilience to bus failures • Increased flexibility • Scalability of replicated buses • Master replication is still feasible Despite these advantages, there are also some drawbacks and limitations: • Increased complexity and price of the master node • Increased complexity of the slave nodes, in some cases • Inflexibility in terms of spacial location of the masters nodes